…cs-12113

The `down` branch always rolled the entire removal phase back, then applied
the caller's count to the additive phase — so a bare `pnpm migrate down`
reverted two migrations (all removal + one additive) instead of the single
latest, and it ignored the combined ordering (removal migrations aren't
necessarily the most recent once an additive migration is added and applied
after them). During local recovery that can silently revert unrelated
destructive changes.

Revert exactly the requested count (default 1) across the combined
newest-first timeline of both phases, using the tracking tables as the source
of truth (--no-check-order lets migrations apply out of filename order).
Consecutive same-phase entries coalesce into one `down K`, so a full-chain
rollback stays ~2 calls rather than one node-pg-migrate invocation per
migration. `determine-changed-migrations.sh` now counts both phases so CI's
full-chain down_count reverts the entire combined chain.

Verified locally: full-chain up/down/up (112+1 → 0 → 112+1, 2 down calls),
bare down reverts only the newest, and an interleave case (fresh additive
applied after the removal) reverts the additive and leaves the removal intact.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…plit

Make the two-phase migration system discoverable and hard to misuse:

- CI guard (scripts/check-removal-phase.cjs, "Guard removal-phase migrations"
  step): AST-parses newly added migrations/ files and fails if an up() drops or
  renames a column/table, pointing to migrations-removal/. Scoped to changed
  files (historical drops grandfathered) and to up() only, so an additive
  migration's down() reversing itself isn't flagged. Uses the TypeScript parser
  (added as a devDependency) rather than a regex so it can distinguish up() from
  down(). Heuristic — covers the rolling-deploy outage class (drop/rename), not
  NOT-NULL tightening or type narrowing.
- `pnpm migrate:create-removal <name>` scaffolds a destructive migration
  straight into migrations-removal/ (via a create-removal case in
  migrate-local.sh), so authoring one no longer needs a manual git mv.
- packages/postgres/README.md documents which directory a migration belongs in,
  how to create each kind, and the twin-table / already-applied-move gotchas.
- .claude/skills/postgres-migrations surfaces the same guidance to agents
  working on migrations.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Describe the failure mode timelessly (a destructive change breaks the previous
code revision during a rolling deploy) rather than citing specific past dates or
counts, which don't help a future reader and rot. Affects the check-removal-phase
guard comment, the postgres README, and the postgres-migrations skill.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Intentionally adds a DROP-in-up() migration to migrations/ (should be in
migrations-removal/) so the "Guard removal-phase migrations" CI check fails.
Remove this commit/file.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

determine-changed-migrations.sh emits a newline-separated file list. Inlining it
into the guard step's run script made each newline a command separator, so the
guard only received the first file and the rest ran as bogus shell commands. Feed
the list through the CHANGED_MIGRATIONS env var and have check-removal-phase.cjs
read and split it, so every changed migration is actually checked without relying
on shell word-splitting.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…iling"

This reverts commit ad7c11d.